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Abstract 

The Formation Flying Test-Bed (FFTB) at NASA Goddard Space Flight Center (GSFC) 
provides a hardware- in- the- loop test environment for formation navigation and control. The 
facility is evolving as a modular, hybrid, dynamic simulation facility for end-to-end guidance, 
navigation, and control (GN&C) design and analysis of formation flying spacecraft. The 
core capabilities of the FFTB, as a platform for testing critical hardware and software 
algorithms in-the-loop, are reviewed with a focus on many recent improvements. Two 
significant upgrades to the FFTB are a message-oriented middleware (MOM) architecture, 
and a software crosslink for inter-spacecraft ranging. The MOM architecture provides a 
common messaging bus for software agents, easing integration, and supporting the GSFC 
Mission Services Evolution Center (GMSEC) architecture via software bridge. Additionally, 
the FFTB’s hardware capabilities are expanding. Recently, two Low-Power Transceivers 
(LPTs) with ranging capability have been introduced into the FFTB. The LPT crosslinks 
will be connected to a modified Crosslink Channel Simulator (CCS), which applies realistic 
space-environment effects to the Radio Frequency (RF) signals produced by the LPTs. 

INTRODUCTION 

Spacecraft formation flying is a concept that continues to attract significant attention; 
Fig. 1. The advantages of formation flying are manifold. The President’s Commission on 
Implementation of United States Space Exploration Policy [2] identifies formation flying as 
one of seventeen enabling technologies needed to meet exploration objectives. 

Both NASA and ESA are evaluating formation flying concepts for numerous planned mis- 
sions. A brief list of currently planned missions include, NASA: Magnetospheric Multi- 
scale (MMS) [20], Constellation-X Observatory [22], Micro- Arcsecond X-Ray Imaging Mis- 
sion [23], Submillimeter Probe of the Evolution of Cosmic Structure [16], Terrestrial Planet 
Finder [15], Stellar Imager [6]; ESA: X-ray Evolving Universe Spectroscopy [9]. In addition, 
'precision formation flying was chosen as one of the five candidate technology capability 
areas for the New Millennium Program’s Space Technology 9 Project [10, 4]. 
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Fig. 1 . Artist’s concept of formation flying spacecraft exchanging information via crosslink. 


PRIOR CAPABILITIES REVIEW 

The Formation Flying Testbed (FFTB) at NASA Goddard Space Flight Center (GSFC) 
allows formation flying navigation and control algorithms to be tested while interacting in 
real-time with the required flight hardware, such as GPS receivers and crosslink transceivers. 
By including hardware directly in the closed-loop testing, researchers and engineers can gain 
valuable information about the interaction and performance of their algorithms, and of the 
performance of the required hardware. 

The following is a brief summary of previously discussed FFTB capabilities. 


Hardware 


A graphical depiction of FFTB hardware connectivity is shown in Fig. 2. The individual 
hardware elements are described in the following, including the FFTB integration status. 

GPS Receivers Currently, the FFTB includes GPS receivers in-the-loop: two Orion re- 
ceivers, four PiVoT receivers, and a single Ashtech G-12. The Orion receivers from the 
German Space Operations Center possess a direct relative navigation feature where GPS 
measurements are exchanged directly via RS-232. The Ashtech receiver is reserved for 
calibration activities. 

GPS Simulator A Spirent® STR4760, with four Radio Frequency (RF) outputs, provides 
simulated GPS constellation signals that stimulate GPS receivers. Each receiver’s antenna 
pattern is configurable. 
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Fig. 2. Hardware interfaces. 

Crosslink Channel Simulator The Crosslink Channel Simulator (CCS) [14] simulates the 
space environment for RF signals used for inter-spacecraft communication and ranging. 
The CCS applies delay, Doppler shift, and attenuation for an RF crosslink between two 
spacecraft, see Fig. 3. At present, the CCS is being modified to support the MMS mis- 
sion [20]. Modifications are nearly complete. The device is expected to be re-integrated 
into the FFTB in the near future. 

Crosslink Transceivers To meet science data collection requirements, on-board spacecraft 
formation controllers must maintain position knowledge. This requires sufficient inter- 
spacecraft communications. To control a formation on the order of kilometers to centime- 
ters, RF communication can be used. Two pairs of RF transceivers are in the process of 
being fully integrated into the FFTB. The Nanosat Cross Link Transceiver (NCLT), devel- 
oped by the Johns Hopkins University Applied Physics Lab, supports integrated crosslink 
communication and relative navigation. The Low-Power Transceiver (LPT) provides inte- 
grated Tracking and Data Relay Satellite System (TDRSS) link and ranging. 


SOFTWARE ARCHITECTURE 


The FFTB software drives soft Real-Time Hardware-in-the-Loop simulations. The simula- 
tion software components are dividend into the following areas. 

Environment 

The Spacecraft Trajectory and Attitude Real-time Simulation (STARS) drives the truth 
spacecraft environment in the FFTB. STARS provides truth orbit and attitude trajectories 
to the overall simulation at a 10 Hz update rate, synchronized to a 1PPS signal provided 
by the Spirent® hardware described previously. Maneuver inputs are accepted by STARS 





Fig. 3. Crosslink Channel Simulator hardware interface. 


in a vehicle’s local reference frame. 

GPS Simulator SimGEN® drives the Spirent® GPS Simulators. STARS feeds true vehicle 
state information directly to SimGEN®, stimulating realistic RF GPS signals. 

Crosslink Channel Simulator The CCS software provides the interface to control the hard- 
ware described previously. This control is performed with User Datagram Protocol (UDP) 
messages over Ethernet. 


Flight Software 


From Fig. 2, each flight computer instantiates a Flight Executive (FE), composed of a col- 
lection of Java/C/C++ programs and MATLAB scripts; see Fig. 4. The FE accepts GPS or 
other sensor measurements and processes them with GEONS [19] for orbit determination for 
navigation and control. A flexible formation controller interface accommodates MATLAB, 
Java, C and C++. 


In the absence of the hardware crosslinks and the CCS, a software crosslink ranging model 
is available to augment position measurements to improve formation knowledge and control. 
Fig. 5 shows the information flow for a two satellite configuration using crosslinks. 

Each FE runs, individually, on a dual-processor Pentium III, clocked at 500 MHz. The choice 
of processor type and speed was intended to emulate the type of on-board computational 
resources available to a physical spacecraft, while permitting a reasonable development 
ability. 
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Fig. 4. Flight Executive connectivity diagram. 
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Fig. 5. Information flow diagram for two satellite simulation with crosslink. 


Visualization 

Full 3-D scene visualization of the real-time simulation data is accomplished with the Satel- 
lite Tool Kit® [3] in combination with FFTB’s adapter software, STKConnect. 


RECENT WORK 

Within the last year, considerable effort was invested to upgrade the FFTB infrastructure 
to provide more computing and simulation hardware resources, as well as to ease component 
integration for customers. 
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Fig. 6. FFTB Messaging System software architecture. 


Computing Infrastructure 


One component of the recent work is a general modernization of the network and computing 
facilities. 

Network Previously, the FFTB internal network was a hub based, 10/100 Mbps, private 
Class C network. This has been replaced with a single switch based, Gigabit, Class C 
network that can operate at full-duplex between capable hardware. For hardware with a 
fixed Ethernet interface of 10/100 Mbps, the network is fully auto- negotiated. 

Computational Resources The software development process in the FFTB has become 
more resource intensive, particularly for the flight software. This prompted the replacement 
of the existing flight computers with single processor HyperThreaded Pentium 4 (6-series) 
units, clocked at 3 GHz. These units contribute to a much more comfortable development 
environment. 

To emulate the computational power of typical flight computers, the updated flight com- 
puters can be stepped down using Intel’s SpeedStep® technology via the Linux cpufreq 
module [5]. The 6-series processors offer eight frequency steps for clocking (KHz): 3000, 
2625, 2250, 1875, 1500, 1125, 750, 375, so providing a range of on-board computing re- 
sources. 


Software 


Message- Oriented Middleware One of the most useful recent developments is the introduc- 
tion of a Message-Oriented Middleware (MOM) layer called the FFTB Messaging System 
(FMS). The goal of introducing the FMS MOM is to significantly reduce the development 
burden when integrating software components into the existing software infrastructure. This 
becomes particularly useful for collaborators that wish to test algorithms within the FFTB, 
allowing more time for testing and evaluation, and reducing component integration time. 
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The FMS architecture, Fig. 6, uses a customized form of the open-source Spread Toolkit [21] 
as the foundation of a publish/sub scribe messaging system, with message definitions main- 
tained by the FMS Interface Control Document (ICD) [11]. In the publish/subscribe model, 
producers publish their messages to clearly defined subject names that follow the naming 
convention prescribed by the GSFC Mission Services Evolution Center (GMSEC) Interface. 
Specification Document [7]. The message consumers then subscribe to the desired sub- 
ject, receiving each message published to that subject. The naming convention states that 
subject names will be a dot (.) delimited string, consisting of upper-case alphanumeric 
characters, the underscore (_), and the dash (-). The subject elements are strictly ordered 
as: System, Mission (constellation or scenario name), Satellite ID, Message Type, Message 
Subtype, Component Name, Message Name. Individual messages are formatted in XML 
version 1.0 [1], where entries are composed of empty-element tags containing {key, type, value) 
information. 

The FMS libraries are available in both Java and C++, and include support for XML 
marshalling and unmarshalling as well as other supporting functionality, e.g. input file 
parsing, state file reader, etc. 

Although the FMS follows the GMSEC subject naming convention, it is not GMSEC compli- 
ant. Currently, there is no open-source GMSEC compliant middleware available. However, 
FMS and GMSEC messages can be exchanged, Fig. 6, via a GMSEC bridge. 


Software Crosslinks As a precursor to implementing hardware crosslinks within the FFTB, 
a software-only crosslink was constructed. This software crosslink clearly defines the inter- 
face and functionality requirements necessary for the hardware crosslink to function in the 
FE. The crosslink channel model is simplistic, and merely corrupts the computed range truth 
with a user defined noise model. The software crosslink subscribes to STARS state messages 
from each of two spacecraft, computes the true range, corrupts the true range with noise, 
and publishes that data with a crosslink subject name, e.g. . . . MSG . RTSD . CROSSLINK . 2WAY. 
The FE accepts a crosslink enabled configuration option, and subscribes to the specified 
crosslink subject. When the FE receives a crosslink measurement, it informs GEONS of 
the measurement type, and provides the measurement for processing. 

With hardware crosslinks and the CCS integrated into the FFTB, the FE treats crosslink 
measurements in the same way. However, the component computing crosslink measurements 
increases in complexity due to multiple hardware interfaces. This complexity is reduced by 
abstracting the higher level functionality as an interface. Thus, hardware specific code is 
repeated within the FE components. This approach is used to address various GPS receivers 
used within the FFTB. 

Visualization In addition to the previously mentioned 3-D full scene visualization devel- 
oped with Satellite Took Kit® and STKConnect, there are several new options for visualiza- 
tion. Full scene 3-D visualization can now be performed with the Jatalizer , which leverages 
the Java Astrodynamics Toolkit (JAT) [12] to perform visualization. In addition to full 
scene visualization, the FFTBPlot tool can be used to graph simulation data that is of 
interest. Since each of the applications is FMS enabled, their data stream can be real-time 
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Fig. 7. Operational diagram for Crosslink Channel Path Simulator, 
or non-real-time depending on the operating mode of the message publisher. 

FUTURE ACTIVITIES 

Future efforts in the FFTB could, for example, expand full-scene visualization or real-time 
plotting capabilities, add software and measurement models, support different orbit regimes, 
acquire new or improved hardware (GPS receivers, crosslinks, etc.), or improve computing 
infrastructure. At present, the FFTB is addressing the following activities. 

Channel Simulators 

The next generation of crosslink simulator, the Crosslink Channel Path Simulator (CCPS) 
seen in Fig. 7, is currently being designed and will support the MMS mission. The CCPS 
will be capable of simulating the crosslinks between four satellites. The hardware is planned 
to have two modes of operation: 


1. accept vehicle state data and compute channel path effect based on internal models, 

2. accept values for Doppler shift, delay, and attenuation from externally computed 
models. 

Automated Rendezvous & Docking 

In addition to formation flying, the President’s Commission on Implementation of United 
States Space Exploration Policy [2] also identifies Automated rendezvous and docking (AR&D) 






as an enabling technology- Extending the FFTB to study AR&D will require the addition 
of models for attitude sensing and algorithms for attitude determination and estimation. 
Once developed, the models and algorithms will require validation to ensure that they meet 
the specified requirements. 

For this effort, the FFTB will maintain its emphasis on closed-loop relative navigation and 
control, and with the final integration of the previously described communication hardware 
and software, will include the effects of communication-in-the-loop on performance. 

Libration Dynamics 

Several of the missions described in the Introduction are evaluating formation flying con- 
cepts with orbits about the collinear Libration points of the Sun-Earth or Earth-Moon 
systems. Modeling the orbital dynamics about a Libration point is considerably different 
from modeling the dynamics of spacecraft motion dominated by a massive central body 
subject to perturbations. Such work will require extension of the truth environment to ac- 
commodate new model dynamics, force models, and integrators. As the AR&D, described 
above, this will also require attitude determination and estimation. 
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